POV-Ray : Newsgroups : povray.advanced-users : Triangle thieves on my harddrive? : Triangle thieves on my harddrive? Server Time
30 Jul 2024 04:20:15 EDT (-0400)
  Triangle thieves on my harddrive?  
From: Charles Fusner
Date: 21 Feb 2000 17:46:20
Message: <38B1B078.69A22723@enter.net>
OK, I'm about 90% done with the experiment I described in my earlier
thread "Simulated Surface Scanning". First I'll digress to say that
I doubt this technique will ever practically yield more than medium
quality results. Even with relatively simple test targets, it leaves
cracking and incomplete scanning artifacts except at the most 
rediculous of mesh densities. The technique is especially ill
suited to sharp edged surfaces, like the edges of a box, prism,
or the flat top and bottom of a cylinder. A *real* solution would,
I'm afraid, require being able to tailor the tesselation to 
specific primitives, and even then, the difficult mathematical 
prims would still be as much a problem as ever. 

Now, along the way, I encountered a few interesting things, like
the fact that the trace() function doesn't like being used against
mesh or mesh2 objects (it crashes MegaPOV entirely the instant
such a situation is encountered) although it doesn't seem to mind
an union of triangles (so it's definitely the mesh structure 
trace() doesn't like, not the triangles themselves). I also found
that 3DWin doesn't like negative vertex references in OBJ files,
as described in the OBJ file specs (crashes 3DWin to attempt to
read such a file) So for practical reasons I decided to stick 
with RAW output. 

I also worked through a half dozen basic misconceptions I had 
about mesh geometry just to get this far, so I was fairly pleased 
up to this point, medium quality scans not withstanding. Even if 
the meshes aren't useful as anything but a scaling and positioning 
references to make other modellers easier to use when building 
specific objects for POV, it still might be of some value. Then, 
I tested the output results, and encountered something I have 
absolutely no idea how to explain anymore, so I'm hoping some mesh 
expert here can at least explain it to me:

When I import any of the meshs I obtained through scanning into
3DWinOGL (or Poser 4 as a prop object) I get a mesh that seems
to be missing about every other triangle. After paring it down
to a simple handwritten file contain just two triangles and 
rotating the view around, I reasoned it has something to do 
with normals, since in the shaded previews, triangles vanish 
altogether when viewed "from the back" so I imported two copies 
of the same mesh into Poser, the second with "Flip normals" 
checked, and sure enough, the second mesh fills in the gaps left 
by the first, so I figured, "oh, so that's what flipped normals 
look like." But I'm scanning as smoothed RAW, therefore supplying 
the normals which resulted from the trace() function, so... 
why should they be imported with every alternate polygon having 
flipped normals when I supplied it with normals that weren't
flipped? This doesn't happen with OBJ and 3DS models I 
have obtained from other sources, so I even tried using
file i/o to output OBJ files directly (to make sure it wasn't
something 3DWin was doing along the way -- it wasn't) so it's 
got to be something specificly having to do with what I'm doing 
during the trace() scan export.

I realize if all this is good for is scaling and position 
references, then all I really need is a mesh that delineates 
the outline of the shape, yet, it bothers me that I can't find 
a reason for this behavior since it demonstrates some gap in 
my knowledge that I'd like to fill in.  So I ask any and all 
mesh experts: Is there something else I don't know about meshes 
normals and quick shading that might cause this? 

Charles


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.